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Abstract 

>- 

This  report  describes  the  derivation  of  a  Viewpoint  Structure  for  a 
Submarine  Combat  System  using  techniques  based  on  soft  systems  theory. 
The  techniques  were  developed  and  applied  by  ARE/UDP  to  assist 
CNOCS(SM)  who  are  using  the  resulting  structure  during  the  development 
of  a  generic  user  specification.  The  report  demonstrates  how  systemic 
techniques  such  as  those  based  on  soft  systems  theory  provide  a 
valuable  adjunct  to  traditional  systematic  techniques  during  the 
requirements  analysis  stage  of  projects  whose  application  domain  is 
sof  t . 
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Derivation  of  Viewpoint  Structure  for  a  Submarine  Combat  System 

Introduction 

1.1  The  importance  of  the  requirements  stage  in  the  development 
life  cycle  of  software  intensive  systems  is  widely  accepted. 
Associated  with  this  is  the  need  to  use  systematic  methods  to 
structure  and  control  the  requirements  specification  process. 
However,  for  large  and  complex  systems  the  production  of  a 
requirements  specification  can  be  very  costly.  To  gain  the 
benefits  of  rigorous  specification  without  repeatedly 
incurring  high  costs  the  Captain  Naval  Operational  Command 
Systems  (CNOCS)  and  the  Admiralty  Research  Establishment  (ARE) 
at  Portsdown  have  pioneered  a  so  called  generic  approach  to 
the  specification  of  requirements  for  surface  ship  command 
systems.  {1,2 ) f-  In  this  way  a  specification  is  built  up  which 
can  be  tailored  to  any  particular  hull. 

1.2  The  part  of  CNOCS  which  deals  with  Submarine  requirements, 

CNOCS(SM),  have  recently  begun  to  generate  a  generic  user 
requirement  for  a  Submarine  Command  System.  The  method  they 
are  using  is  similar  to  that  being  used  by  CNOCS  for  surface 
ships  and  is  loosely  based  on  the  Controlled  Requirements 
Expression  (CORE)  method.  The  output  produced  by  CNOCS (SM) 
can  be  used  by  analysts  applying  the  CORE  method  proper  to 
arrive  at  a  Logical  System  Description.  This  is  made  possible 
because  both  users  and  analysts  share  the  same  viewpoint 
structure.  This  paper  describes  how  ARE/UDP  at  Portland 
provided  support  to  CNOCS(SM)  in  deriving  a  viewpoint 

structure  for  a  Submarine  Combat  System,  which  includes  the 
Command  System.  The  method  used  by  UDP  drew  on  a  number  of 
ideas  from  soft  systems  theory  with  results  that  clearly 
demonstrate  the  usefulness  of  these  ideas  applied  to  the 
requirements  analysis  stage  of  large  complex  systems.  The 
emphasis  in  this  paper  is  the  description  of  the  method  used 
to  arrive  at  a  viewpoint  structure,  for  a  full  description  of 
the  resulting  structure  reference  [8)  should  be  read. 

1.3  This  paper  is  in  six  main  sections.  The  first  two  sections 
provide  the  background  and  major  concepts  of  soft  systems 
theory.  The  third  section  deals  with  the  project  life  cycle 
as  a  particular  example  of  the  more  general  problem  solving 

Erocess  and  shows  how  the  ideas  behind  soft  systems  theory  can 
e  transferred  from  one  to  the  other.  The  next  two  sections 
deal  with  the  particular  application  of  soft  systems  theory  to 
arrive  at  a  CORE  viewpoint  diagram  of  a  Submarine  Combat 
System.  The  final  major  section  discusses  the  results  and 
provides  a  brief  description  of  some  future  work. 

-■A 

Systems  Thinking  ; 

2.1  The  term  system  is  probably  one  of  the  most  overworked  in 
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current  use.  Everybody  knows  one  when  they  see  one  and 
possibly  because  of  this  a  universally  accepted  definition  of 
a  system  is  not  easily  arrived  at.  The  dictionary  defines  a 
system  as  a  structured  set  of  objects  and/or  attributes 
together  with  the  relationships  between  them.  A  system 
contains  elements  which  have  some  reason  for  being  taken 
together,  but  it  is  more  than  just  a  set,  it  also  includes  the 
relationships  that  exist  between  the  elements  of  that  set. 
Systems  thinking  comprises  all  the  ideas  and  concepts  which 
derive  from  the  definition  of  a  system. 

2.2  The  noun  system  gives  rise  to  the  two  adjectives  systemic  and 
systematic  which  describe  the  ways  in  which  systems  thinking 
is  currently  applied.  Checkland  [3]  defined  the  following 
mutually  exclusive  paradigms  which  attempt  to  make  the 
distinction  clear 

a.  Paradigm  I.  The  real  world  is  composed  of  systems; 
therefore  methods  for  dealing  with  it  may  be  systematic. 

b.  Paradigm  II.  The  true  nature  of  the  real  world  is 
uncertain;  however,  it  can  be  modelled  by  systems  using 
systemic  methods. 


2.3  Systematic  methods  need  have  little  or  no  systems  content, 
they  merely  rely  on  the  fact  that  systems  exist.  Much  of 
current  systems  engineering  is  based  upon  paradigm  I. 
Systemic  methods  actively  and  explicitly  use  systems  to 
achieve  their  aim.  The  application  of  systems  thinking  to  the 
problem  solving  process  demonstrates  each  paradigm  and 
identifies  the  need  for  systemic  methods  to  deal  with 
situations  where  paradigm  II  applies. 

2.4  A  model  of  the  problem  solving  process  is  shown  in  figure  1. 
The  problem  formulation  stage  is  about  deciding  what  has  to  be 
done,  whilst  the  decision  making  stage  is  about  deciding  how 
to  do  it.  Models  are  used  in  both  stages.  During  problem 
formulation  models  are  used  to  record  and  structure  knowledge 
of  the  application  domain  whilst  during  decision  making  models 
are  used  to  experiment  with  various  candidate  solutions. 

2.5  If  the  problem  solving  process  is  itself  designed  to  be  a 
system  then  it  can  be  understood  and  managed  by  the  use  of 
systematic  rules  and  procedures.  During  problem  formulation 
the  important  question  is  whether  systems  exist  within  the 
application  domain  as  objective  entities?  If  the  application 
domain  is  a  designed  physical  system,  for  example  a  radio 
receiver,  then  it  may  be  safe  to  assume  that  systems  exist  in 
the  required  sense  and  so  the  problem  formulation  stage 
becomes  no  more  than  expressing  the  detail  of  a  system  which 
already  exists.  Obviously  systematic  procedures  can  be 
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employed  to  do  this.  If  however  the  application  domain  cannot 
with  certainty  be  said  to  contain  systems  then  a  simple 
systematic  approach  to  problem  formulation  cannot  be  taken. 
Problem  formulation  then  becomes  a  much  more  difficult 
activity  which  involves  modelling  in  its  proper  sense.  Rather 
than  simply  describing  something  which  already  exists  a 
structure  must  be  found  which  is  applicable  to  the  problem 
under  consideration.  This  is  where  systemic  principles  are  of 
use . 

2.6  Application  domains  which  are  structured  and  within  which 
systems  exist  as  objective  entities  are  referred  to  as  being 
hard.  Application  domains  whose  true  nature  is  uncertain  are 
referred  to  as  soft.  Hard  application  domains  require  less 
problem  formulation  than  soft  and  are  more  often  capable  of 
being  described  in  purely  mathematical  terms.  However,  it 
should  not  be  thought  that  domains  are  simply  hard  or  soft, 
rather  it  is  the  limits  put  on  the  application  domain  which 
determine  its  nature.  For  example  considering  a  motor  car  as 
a  mechanical  device  provides  a  hard  domain,  whereas 
considering  a  motor  car  as  a  means  of  transport  makes  the 
domain  much  softer. 

2.7  Further  understanding  of  the  differences  between  hard  and  soft 
domains  can  be  obtained  by  considering  the  types  of  system 
used  to  model  each.  This  requires  a  classification  scheme  for 
systems  and  the  one  used  in  this  report  is  as  follows 

a.  Natural  Systems.  Natural  systems  are  physical  systems 
which  make  up  the  Universe  in  a  hierarchy  from  subatomic 
systems  through  the  systems  of  ecology  to  galactic 
systems . 

b.  Designed  Systems .  Designed  systems  can  be  both 
physical  (tools,  bridges)  and  abstract  (mathematics, 
language)  . 

c.  Human  Activity  Systems.  Human  activity  systems  are 
human  beings  undertaking  purposeful  activity  such  as 
man-machine  systems,  industrial  activity  and  political 
systems . 

d.  Social  and  Cultural  Systems .  Most  human  activity  will 
exist  wTthin  a  social  system  where  the  elements  will  be 
human  beings  and  the  relationships  will  be  interpersonal. 
An  example  of  a  social  system  would  be  the  family. 

2.8  Hard  application  domains  are  normally  described  in  terms  of 
designed  systems.  The  most  important  systems  for  modelling 
soft  application  domains  are  human  activity  systems.  However, 
human  activity  systems  do  not  exist  in  isolation.  A  human 
activity  system  will  also  involve  a  social  system  and  will 
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probably  make  use  of  a  designed  system. 

2.9  Soft  systems  theories  are  about  human  activity  systems  and  how 
they  can  be  used  to  model  soft  application  domains.  The  next 
section  describes  a  number  of  specific  techniques  which  can  be 
used  in  building  sue  models. 

3  Soft  Systems  Theory 

3.1  This  section  begins  with  a  more  detailed  definition  of  a  human 
activity  system  (HAS)  which  is  summarised  in  the  formal 
systems  model.  This  is  followed  by  a  description  of  the  soft 
systems  techniques  which  were  adapted  for  use  in  deriving  the 
submarine  combat  system  viewpoint  structure. 

3.2  The  most  basic  characteristic  of  a  HAS  is  that  it  is  concerned 
with  transformation  processes.  A  HAS  is  therefore  modelled  as 
the  interconnected  set  of  activities  which  are  required  to 
transform  some  inputs  into  some  outputs.  This  transformation 
must  be  to  some  purpose  and  this  gives  rise  to  the  concept 
that  a  HAS  is  purposeful.  The  existence  of  purpose  means  that 
the  system  can  measure  its  performance  and  use  these 
measurements  to  make  decisions  that  will  improve  future 
performance.  These  characteristics  are  combined  with  others 
applicable  to  all  systems  to  define  the  following  formal 
systems  model  which  states  that  a  HAS 

a.  has  an  on-going  purpose. 

b.  exhibits  connectivity  between  activities. 

c.  can  define  measures  of  performance. 

d.  has  monitoring  and  controlling  mechanisms. 

e.  has  decision-taking  procedures. 

f.  exists  within  a  boundary. 

g.  makes  available  and  uses  resources. 

h.  is  part  of  a  systems  hierarchy. 

3.3  Unlike  designed  systems  human  activity  systems  do  not  exist  as 

objective  realities.  What  do  exist  are  perceptions  of  them  in 
the  heads  of  observers.  Returning  to  the  example  of  a  motor 
car  first  introduced  in  section  2  above,  if  it  is  taken  as  a 
designed  physical  system  then,  given  the  same  degree  of 
competence  in  observers,  complete  agreement  could  be  obtained 
on  a  description  of  it.  If,  however,  the  motor  car  is 

considered  in  terms  of  its  use  as  part  of  a  human  activity 
system  then  no  degree  of  competence  amongst  observers  would 
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necessarily  result  in  the  same  description.  Some  might  see  it 
in  terms  of  a  profit  producing  system,  others  a  pollution 
producing  system  and  yet  others  as  a  system  to  provide 
mobility. 

3.4  The  fact  that  there  are  multiple  views  of  the  application 
domain  which  are  possible  and  valid  is  of  crucial  importance 
in  attempting  to  use  human  activity  systems  as  a  modelling 
formalism.  This  concept  of  multiple  views  is  described  by  the 
German  word  Weltanschauung,  which  means  world  view.  It  is  an 
individual's  world  view  which  enables  him  to  attribute  meaning 
to  what  is  observed.  There  will  therefore  be  many  possible 
human  activity  system  models  relevant  to  a  given  soft  domain, 
each  corresponding  to  a  different  observer's  world  view. 

3.5  Human  activity  systems  are  defined  by  root  definitions.  A 
root  definition  should  detail  the  following  about  the  system 
it  specifies 

a.  Ownership.  The  owners  of  the  system  or  a  wider  system 
which  may  discourse  about  the  system. 

b.  Actors .  The  agents  who  carry  out,  or  cause  to  be 
carried  out,  the  transformation  processes  or  activities 
of  the  system. 

c.  Transformations .  The  core  of  the  root  definition; 
transformation  processes  carried  out  by  the  system. 

d.  Customer .  Client,  beneficiary  or  victim  affected  by 
the  main  activities  of  the  system. 

e.  Environment .  Environmental  impositions  and 

interactions . 

f.  World  View .  The  outlook  and  framework  which  makes  the 
root  definition  a  meaningful  one. 

3.6  Root  definitions  and  the  formal  systems  model  provide  the 

basis  for  a  soft  systems  modelling  technique  developed  by 
Checkland  [4]  called  issue  based  analysis.  This  technique 
aims  to  help  solve  problems  within  an  essentially  soft 
applications  domain.  As  such  it  covers  problem  formulation 
(stages  1  -  5) ,  decision  making  (stage  6)  and  taking  action 

(stage  7) .  The  major  stages  in  Checkland's  approach  are  shown 
in  figure  2  and  described  below 

a.  Stages  1^  and  2 .  Stages  1  and  2  are  an  expression 
phase  during  which  time  an  attempt  is  made  to  build  up 
the  richest  possible  picture  of  the  application  domain. 

b.  Stage  3 .  Stage  3  involves  preparing  root  definitions 
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of  some  human  activity  systems  which  might 
the  application  domain.  The  use  of 
definitions  recognises  the  multiple 
conflicting  perceptions  of  the  domain. 


be  relevant  to 
several  root 
and  perhaps 


c.  Stage  4 .  Stage  4  constructs  models  for  each  of  the 
root  definitions.  The  modelling  language  is  based  upon 
verbs  and  the  model  consists  of  interconnected  activities 
(described  by  the  verbs).  The  model  is  compared  with  the 
formal  systems  model  (see  para  3.5  above)  to  ensure  it  is 
not  fundamentally  flawed  in  some  way. 

d.  Stage  5 .  Stage  5  compares  the  conceptual  models  built 
in  stage  4  with  the  situation  expressed  in  stage  2  in 
order  to  generate  debate  with  relevant  people  from  the 
application  domain. 


e.  Stages  and  7 .  The  debate  generated  during  stage  5 
should  result  in  the  definition  of  desirable  and  feasible 
changes  during  stage  6.  Stage  7  then  involves  taking 
action  based  on  stage  6  to  improve  the  situation. 


3.7  Wilson  [5]  has  introduced  the  idea  of  a  primary  task  root 
definition.  A  primary  task  root  definition  attempts  to  arrive 
at  a  description  of  a  human  activity  system  which  all 
observers  can  agree  upon.  In  as  far  as  is  possible  primary 
task  root  definitions  should  be  independent  of  any  particular 
world  view.  In  [5]  Wilson  gives  the  example  of  a  prison  which 
was  taken  to  be  'a  system  for  the  receipt,  storage  and 
despatch  of  prisoners'.  Such  definitions  have  been  found  to 
be  useful  in  carrying  out  requirements  analysis  for 
information  systems  in  soft  domains.  Wilson  goes  on  to  state 
that  a  primary  task  definition  is  always  preceeded  by  an  issue 
based  analysis  which  helps  decide  what  should  be  taken  as  the 
primary  task  definition. 


3.8  Wilson  models  his  primary  task  root  definitions  in  the  same 
way  as  Checkland.  Validation  of  the  resulting  model  is 
carried  out  by  comparing  it  with  the  application  domain.  If, 
as  is  intended,  the  primary  task  root  definition  somehow 
expresses  the  essential  nature  of  an  organisation  then  for 
each  'what"  in  the  model  there  should  be  a  corresponding  'how' 
in  the  application  domain.  It  is  sufficient  to  identify  a 
'how'  no  matter  how  inefficient  or  ineffective  it  is.  Failure 
to  identify  a  'how'  would  indicate  that  the  primary  task  root 
definition  is  wrong. 

3.9  Each  of  the  activities  in  the  model  of  a  root  definition  may 
itself  become  the  object  of  analysis,  first  issue  based  and 
then  primary  task.  In  this  way  an  application  domain  can  be 
decomposed  as  shown  in  figure  3. 
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3.10  In  the  next  section  the  need  for  soft  systems  ideas  in  the 
development  of  computer  based  management  systems  is  identified 
prior  to  a  discussion  of  how  this  need  has  been  met  at  ARE 
Portland  by  adapting  the  techniques  just  described. 

4  Requirements  Analysis  and  the  Project  Li f e  Cycle 

4.1  The  software  crisis  of  the  1960's  led  to  the  growth  of 

software  engineering  and  the  adoption  of  a  number  of 

established  ideas  from  traditional  engineering  disciplines. 
Amongst  the  most  important  of  these  ideas  was  a  model  of  the 
development  process  called  the  project  life  cycle.  A 

waterfall  model  of  the  life  cycle  is  shown  in  figure  4. 

4.2  The  project  life  cycle  can  be  considered  a  particular  case  of 
the  more  general  problem  solving  process,  where  requirements 
analysis  equates  to  problem  formulation  (what  to  do)  ,  design 
equates  to  decision  making  (how  to  do  it)  and  implementation 
equates  to  taking  action  (do  it) .  Given  the  similarities 
between  the  project  life  cycle  and  the  problem  solving  process 
the  nature  of  the  application  domain  can  be  seen  to  have  the 
same  importance  for  both  in  the  selection  of  methods. 

4.3  Existing  methods  for  requirements  analysis  tend  to  be 

systematic  rather  than  systemic,  being  more  concerned  with 
expressing  the  requirement  than  with  structuring  the 

application  domain.  For  some  hard  application  domains  a 
purely  systematic  approach  can  be  used,  for  example  in 
specifying  the  requirement  for  an  automatic  reactor  control 
system,  although  even  here  the  application  domain  is  made  hard 
only  by  a  suitably  narrow  definition  of  the  system's  boundary. 
However,  for  soft  application  domains,  such  as  Naval  Command 
and  Control,  a  systemic  approach  is  necessary. 

4.4  The  requirements  phase  of  the  life  cycle  is  therefore  at  the 
minimum  a  two  stage  activity,  the  first  being  to  structure  the 
application  domain  and  the  second  to  express  the  structure 
obtained.  Application  domains  are  hard  or  soft  depending  on 
the  amount  of  structuring  required,  hard  domains  requiring 
less  structuring  than  soft.  Purely  systematic  approaches  are 
suitable  for  hard  domains  but  systemic  approaches  are  required 
in  soft  domains. 

4.5  The  classification  of  domains  as  hard  or  soft  together  with 
the  realisation  that  different  techniques  are  required  to  deal 
with  each  has  important  consequences  for  software  engineering. 
As  an  example  consider  the  transformational  model  of  the 
project  life  cycle,  where  software  development  is  seen  as  a 
series  of  transformations  between  different  system 
representations.  If  these  transformations  and  system 
representations  are  in  some  sense  formal  then  so  are  the 
processes  of  verification  and  validation.  Verification  is 
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defined  as  checking  for  the  correctness  between  one  system 
representation  and  the  next,  whilst  validation  is  seen  as 

checking  for  correctness  (or  correspondence)  between  any 

transformed  system  representation  and  the  application  domain. 
If,  however,  the  application  domain  is  not  an  objective  system 
then  the  form  of  validation  proposed  by  this  model  is  not 
possible.  This  issue  is  further  discussed  in  (6). 

4.6  The  difficulty  of  arriving  at  a  satisfactory  specification  of 

soft  application  domains  using  purely  systematic  methods  has 
already  been  recognised  by  software  engineers,  many  of  whom 
have  seen  the  answer  to  be  the  building  of  prototypes. 
However,  this  is  really  no  more  than  a  form  of  issue  based 

analysis  where  the  models  are  not  on  paper  but  are  actually 

built.  They  are  then  compared  with  the  application  domain  by 
allowing  actors  to  use  the  prototype.  From  this  experience 
the  model  may  be  modified  (another  prototype  built)  or  a 
design  developed.  Checkland  style  issue  based  analysis 
followed  by  a  primary  task  analysis  provide  an  alternative  to 
prototyping  in  soft  application  domains  and  is  the  approach 
adopted  for  the  initial  requirements  analysis  of  Submarine 
Combat  Systems. 

4.7  The  Controlled  Requirements  Expression  (CORE)  method  [7]  is 
essentially  a  systematic  approach  to  requirements  analysis. 
However,  it  has  the  advantage  over  many  other  methods  of 
formally  recognising  and  dealing  with  the  fact  that  there  may 
be  many  different  views  of  the  system.  These  different  views 
are  combined  and  recorded  in  a  viewpoint  diagram  which  then 
becomes  the  basis  of  subsequent  analysis.  Many  different 
views  are  exactly  the  characteristics  of  soft  application 
domains.  Unfortunately  CORE  gives  only  very  general  advice  on 
how  to  arrive  at  the  viewpoints  themselves  or  extract 
information  relevant  to  each. 

4.8  ARE/UDP  decided  to  use  soft  systems  techniques  based  on  root 
definitions  to  arrive  at  the  viewpoints  of  a  submarine  combat 
system  and  establish  the  framework  for  the  collection  of  data 
about  each  one.  In  the  next  section  the  use  of  CORE  by  CNOCS 
and  ARE  Portsdown  is  reviewed,  followed  by  a  description  of 
how  soft  systems  theory  has  been  integrated  with  CORE  at  ARE 
Portland . 

5  Method  for  Viewpoint  Analysis 

5.1  ARE  Portsdown  decided  to  use  CORE  as  the  means  of  arriving  at 
a  logical  system  description  of  a  surface  ship  comand  system. 
They  made  a  number  of  improvements  to  the  basic  method  amongst 
which  was  the  development  of  internal  viewpoints. 
Conventionally  the  viewpoint  structure  breaks  the  environment 
of  the  proposed  system  into  its  component  parts.  The  proposed 
system  can  be  analysed  from  the  viewpoint  of  each  of  the 
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entities  that  exchange  information  with  it.  These  viewpoints 
may  be  termed  external.  ARE  Portsdown  also  introduced  the 
idea  of  having  internal  viewpoints  which  represent  a 
decomposition  of  the  target  system.  The  required 
functionality  is  described  in  terms  of  each  of  these  internal 
viewpoints.  Data  collection  is  based  upon  the  internal  leaf 
viewpoints  and  is  provided  by  users  nominated  by  CNOCS. 

5.2  Users  found  that  the  provision  of  data  to  the  CORE  analysts 
for  each  of  the  required  internal  viewpoints  was  excessively 
difficult.  CNOCS  therefore  developed  a  technique  to  obtain 
the  required  data.  This  involved  developing  templates  of  the 
generic  activities  which  must  take  place  within  each  viewpoint 
for  which  data  were  needed,  the  so  called  leaf  viewpoints 
within  the  command  system.  These  templates  were  then 
instantiated  by  considering  the  specific  tasks  required  of 
each  viewpoint  and  naming  the  functions  which  are  implied  by 
the  relevant  activity  template  in  order  that  the  task  can  be 
done.  The  CNOCS  output  became  known  as  the  user  requirements 
specification  and  is  used  by  ARE  Portsdown  to  produce  a 
logical  system  description. 

5.3  The  initial  work  required  at  ARE  Portland  in  order  that 

CNOCS(SM)  could  begin  to  generate  the  submarine  user 

requirement  was  therefore  the  development  of 

a.  a  submarine  viewpoint  diagram,  incorporating  the 
concept  of  internal  viewpoints. 

b.  activity  templates  for  leaf  viewpoints  within  the 
command  system. 

5.4  The  same  method  was  used  to  arrive  at  the  viewpoint  structure 
and  the  activity  templates.  The  method  comprises  cycles  of 
issue  based  analysis  followed  by  primary  task  analysis.  The 
overall  method  is  shown  in  figure  5  and  described  below. 

5.5  For  each  cycle  of  application  of  the  method  an  object  system 

was  chosen  and  a  number  of  root  definitions  developed  and 

modelled.  These  were  then  used  to  arrive  at  a  primary  task 

root  definition  and  model.  This  primary  task  model  was 
partitioned  into  subsystems  which  became  viewpoints  and 
potential  objects  for  analysis  during  subsequent  cycles  of  the 
method.  At  the  lowest  level  of  decomposition  the  primary  task 
models  became  the  basis  for  activity  templates  of  the  relevant 
viewpoints . 

5.6  The  derivation  of  root  definitions  and  models  as  part  of  the 

issue  based  analysis  was  carried  out  during  structured 
interviews  with  a  number  of  Submarine  Qualified  Officers 

serving  within  CNOCS(SM),  FOSM,  DNW  and  The  First  Submarine 
Squadron.  Primary  task  root  definitions  and  models  were 
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developed  by  CNOCS(SM)  with  ARE/UDP  assistance. 

5.7  In  the  next  section  the  results  of  applying  this  method  are 
presented . 

6  Derivation  of  a  Submarine  Combat  System  Viewpoint  Diagram 

6.1  The  ARE  Portsdown  definition  and  decomposition  of  the 
operational  maritime  environment  was  initially  accepted 
without  further  analysis.  This  decomposition  consisted  of 
five  viewpoints  as  follows 

a.  Higher  Level  Command,  which  comprises  those  parts  of 
the  operational  maritime  environment  which  are  superior 
to  and  can  direct  the  operations  of  the  subject  combat 
system . 

b.  Subordinate  Combat  Systems,  which  comprises  those 
combat  systems  under  the  direction  of  the  subject  combat 
system . 

c.  Combat  System,  which  is  the  subject  of  study  and  the 
CORE  target  system. 

d.  Other  Combat  Systems,  which  comprises  those  friendly 
combat  systems  over  whom  the  subject  combat  system  has  no 
control  and  who  in  turn  exercise  no  control  over  it. 

e.  Environment,  which  comprises  all  other  factors  which 
influence  or  are  influenced  by  the  subject  combat  system. 

6.2  Work  began  with  the  decomposition  of  the  Combat  System 
viewpoint.  Application  of  the  method  described  in  section  5 
above  resulted  in  the  primary  task  root  definition  of  a 
Submarine  Combat  System  which  identified  it  as 

“A  Higher  Level  Command  owned.  Submarine  crew  operated 
system  which  receives  and  transforms  directives  from 
higher  command  into  successfully  completed  actions  making 
use  of  Combat  System  resources  and  taking  account  of  the 
perceived  operational  maritime  environment  derived  within 
the  Combat  System  from  reports  received  and  measurements 
taken' . 

6.3  This  root  definition  has  the  following  elements,  based  on  para 
3.5  above 

a.  Owners:  Higher  Level  Command. 

b.  Actors:  The  Submarine  (crew). 

c.  Transformation:  Directives  into  actions. 
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d.  Customer:  Higher  Level  Command. 

e.  Environment:  The  Operational  Maritime  Environment. 

f.  World  View:  The  combat  system  provides  a  means  for 
higher  level  command  to  carry  out  its  objectives. 

6.4  This  root  definition  resulted  in  the  model  of  figure  6.  The 
model  activities  were  grouped  together  to  form  three 
sub-systems  or  viewpoints  for  further  analysis,  giving  rise  to 
the  viewpoint  structure  of  figure  7. 

6.5  Subsequent  analysis  of  the  resource  system  viewpoint  showed 
that  in  fact  it  was  two  viewpoints.  One,  which  retained  the 
name  resource  system,  interfaced  directly  with  the  operational 
maritime  environment  and  provided  the  primary  means  by  which 
the  combat  system  carried  out  actions  to  meet  the  needs  of 
higher  level  command.  The  other  system,  which  was  termed  the 
support  system,  did  not  interface  directly  with  the 
operational  maritime  environment  but  was  concerned  with 
providing  services  to  other  combat  system  components.  The 
information  system  previously  identified  as  a  separate  level  2 
viewpoint  was  more  correctly  seen  to  be  part  of  the  support 
system  and  was  merged  with  it.  The  modified  viewpoint  diagram 
is  shown  in  figure  8. 

6.6  The  following  primary  task  root  definitions  were  developed  for 
each  of  the  level  2  viewpoints  shown  in  figure  8 

'The  management  system  is  a  combat  system  owned,  command 
team  operated  system  which  plans,  co-ordinates  and 
directs  the  operations  of  the  support  and  resource 
systems  to  meet  the  needs  of  higher  level  command  and  in 
response  to  events  in  the  perceived  operational  maritime 
environment' 

'The  resource  system  is  a  combat  system  owned,  submarine 
crew  operated  system  which  acts  in  the  Operatioal 
Maritime  Environment  to  fulfil  tasks  allocated  by  the 
management  system' 

'The  support  system  is  a  combat  system  owned,  submarine 
crew  operated  system  which  responds  to  demands  from  other 
combat  system  components  to  provde  the  services  they 
require  to  carry  out  their  allocated  tasks' 

6.7  Each  of  the  root  definitions  in  para  6.6  was  modelled  and  the 
activities  grouped  to  give  level  3  sub-systems  or  viewpoints. 
The  resulting  viewpoint  structure  is  shown  in  figure  9. 

6.8  It  can  be  seen  that  each  of  the  management,  resource  and 
support  systems  consists  of  three  viewpoints.  These  are  a 
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management  viewpoint  (configuration  management,  resource 
system  management  and  support  system  management) ,  an 
information  handling  viewpoint  (management  information  system, 
resource  information  system  and  support  information  system) 
and  an  action  viewpoint  (mission  management,  take  action 
system  and  provide  services  system).  Configuration  management 
is  the  name  chosen  for  what  might  be  termed  management  system 
management.  Configuration  management  organises  management 
system  activities  and  resources  in  order  that  they  can  carry 
out  their  tasks. 

6.9  The  level  2  management  system  manages  the  whole  combat  system 
whilst  each  of  the  level  3  management  viewpoints  manages  a 
level  2  system.  Equally  the  original  level  2  information 
system  handled  information  for  the  whole  combat  system,  whilst 
each  of  the  level  3  information  systems  handles  information 
within  a  level  2  system.  It  should  be  noted  that  the  support 
system  includes  the  information  system  which  serves  the  whole 
combat  sytem,  but  this  is  conceptually  different  from  the 
support  information  system  which  is  only  concerned  with 
handling  information  within  the  support  system. 

6.10  The  viewpoint  structure  of  figure  9  represents  an  important 
stage  in  the  analysis  of  a  Submarine  viewpoint  structure  in 
that  a  number  of  different  decompositions  could  be  made  from 
it.  The  actual  decomposition  chosen  was  based  upon  the 
following  pragmatic  decisions 

a.  that  all  management  viewpoints  would  be  grouped  under 
a  single  dedicated  management  system. 

b.  that  all  information  viewpoints  would  be  taken  to 
form  part  of  a  wider  information  system  that  forms  the 
major  part  of  the  support  system. 

6.11  The  first  decision  was  taken  in  an  attempt  to  retain  some 
degree  of  commonality  with  the  Surface  Ship  Viewpoint 
Structure.  The  second  decision  followed  from  the  first.  If 
the  level  3  information  viewpoints  were  primarily  handling 
information  between  the  action  and  management  viewpoints,  by 
moving  the  management  viewpoints  in  the  way  described  above 
this  information  flow  changed  from  being  internal  to  the  level 
2  systems  to  being  across  the  whole  combat  system.  It 
therefore  made  sense  to  merge  the  level  3  information 
viewpoints  into  the  level  2  support  system. 

6.12  With  the  level  3  management  and  information  viewpoints 
rearranged  the  support  and  resource  systems  become  no  more 
than  action  viewpoints  which  need  no  level  3  decomposition  at 
this  stage  of  the  analysis.  The  resulting  modified  viewpoint 
structure  is  shown  in  figure  10. 
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6.13  Further  root  definitions  and  models  were  developed  for  each  of 
the  leaf  viewpoints  within  the  management  system.  The  models 
developed  at  this  stage  became  the  basis  for  the  activity 
templates  shown  in  figures  11-13. 

6.14  The  viewpoint  structure  of  figure  10  was  further  extended 

pragmatically  to  reflect  the  physical  systems  and  domain 
experts  known  to  exist  and  forming  parts  of  the  support  and 
resource  systems.  Inspection  of  figure  10  also  lead  to  a 
minor  change  in  the  breakdown  of  the  Operational  Maritime 

Environment.  This  involved  removing  subordinate  combat 
systems  and  other  combat  systems,  and  introducing  the  new 

viewpoint  representing  assigned  combat  systems.  The  final 
form  of  the  Submarine  Combat  System  Viewpoint  Structure  is 
shown  in  figure  14  and  described  in  detail  in  [8]. 

7  Discussion 

7.1  The  resulting  viewpoint  structure  of  figure  14  is  not  unique. 

From  the  structure  of  figure  9  a  very  different  decomposition 
could  have  been  undertaken,  the  actual  decomposition  used 
being  heavily  influenced  by  pragmatic  considerations.  The 
fact  that  it  is  not  immediately  obvious  whether  the 

description  of  figure  14  is  in  some  objective  sense  better  or 
worse  than  any  alternative  decomposition  based  on  figure  9 
illustrates  the  soft  nature  of  a  Submarine  Combat  System  as  an 
application  domain  for  information  systems  analysis.  CORE 
only  requires  that  the  viewpoint  structure  be  sufficiently 
rich  to  capture  the  whole  requirement  and  it  is  considered 
that  figure  14  meets  this  criteria. 

7.2  The  level  of  decomposition  at  which  the  viewpoint  analysis  was 
terminated  was  an  arbitrary  decision.  The  method  described  in 
this  paper  could  certainly  have  been  applied  to  decompose  the 
structure  further.  Nevertheless  the  structure  has  been 
decomposed  sufficiently  to  demonstrate  the  usefulness  of  soft 
systems  theory  as  applied  to  the  analysis  of  requirements  in 
essentially  soft  application  domains. 

7.3  However,  by  stopping  at  level  4  certain  issues  remain 
insufficiently  well  addressed.  Each  of  the  models  of  leaf 
viewpoints  contains  activities  which  themselves  represent  on  a 
smaller  scale  the  full  range  of  application  domains  from  hard 
to  soft.  For  example  'monitor  status'  represents  a  relatively 
hard  activity,  whereas  'assess  the  situation'  and  'determine 
planning  requirements'  represent  soft  activities.  CORE  is 
very  good  at  expressing  the  requirement  in  terms  of  these  hard 
activities  but  the  complete  specification  of  the  softer 
activities  is  more  problematic.  The  softer  activities  are  in 
many  respects  equivalent  to  the  non-programmed  decisions  of 
Simon  [9]  and  represent  potential  areas  for  decision  support. 
As  described  in  Keen  and  Scott  Morton  [10]  the  methods  for 
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specifying  and  designing  decision  support  are  very  different 
from  the  techniques  provided  by  CORE.  There  is  therefore  the 
need  first  to  provide  techniques  for  identifying  the  soft 
activities  at  level  4  and  below,  and  second  to  find  methods 
for  arriving  at  adequate  requirements  specifications  for  these 
activities . 


7.4  By  rearranging  the  viewpoint  structure  of  figure  9  in  the  way 
described  in  paras  6.10  -  6.12  most  of  the  soft  activities 

have  been  concentrated  within  the  management  system.  It  is 
therefore  possible  that  subsequent  analysis  will  show  a 
progression  from  hard  activities  to  increasingly  soft 
activities  in  moving  from  the  resource  system,  through  the 
support  system  and  into  the  management  system.  Systematic 
techniques  such  as  CORE  applied  without  modification  may  be 
able  to  adequately  specify  resource  system  and  many  support 
system  requirements,  however,  considerable  difficulty  may  be 
encountered  arriving  at  a  satisfactory  requirement  for  the 
management  system  in  this  way. 


7.5  Further  application  of  soft  systems  ideas  may  help  in  arriving 
at  an  adequate  requirements  within  the  management  system.  The 
identification  and  specification  of  soft  activities  will  be 
the  subject  of  future  work  and  papers  as  part  of  the  logical 
system  description  of  a  Submarine  combat  system  being  produced 
by  ARE  Portland  for  DGCC . 


8  Conclualona  and  Raconunendations 

8.1  Conclusions .  The  structuring  of  soft  application  domains 
provides  a  non-trivial  problem  which  is  inadequately  dealt 
with  by  systematic  methods  for  requirements  analysis  and 
specification.  Soft  systems  theory  provides  a  set  of 
techniques  which  can  be  adapted  for  use  with  systematic 
methods,  in  this  case  CORE,  to  overcome  the  deficiencies  of 
the  latter.  A  specific  example  of  how  this  can  be  done  is 
provided  by  the  derivation  of  a  viewpoint  structure  of  a 
Submarine  Combat  System  described  in  this  report. 


8.2  Recommendations .  It  is  recommended  that  the  viewpoint 
structure  of  figure  14  be  adopted  by  ARE/UDP  and  CNOCS(SM)  for 
all  future  work  concerned  with  the  specification  of 
requirements  for  submarine  combat  systems. 
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Figure  2.  :  CHECKLANDS’ SOFT  SYSTEMS  METHODOLOGY 
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